This invention relates to a method of, and system for, handling multiple backup processes.
The storage of data in large organisations is of fundamental importance, both for reliability of the data and for the ability to recover data in the event of any hardware failure. Storage area network (SAN) is an architecture that is used when very large amounts of data are needed to be stored in a reliable and secure manner. This technology allows networks to be created that support the attachment of remote computer storage devices such as disk arrays to servers in such a way that, to the operating system, the devices appear as locally attached. It is common in these networks to include a large amount of redundancy, both in the data storage and in the hardware connections between the individual components.
Various methods exist for creating data redundancy. For example, a function such as a FlashCopy® function enables an administrator to make point-in-time, full volume copies of data, with the copies immediately available for read or write access. (FlashCopy is a registered trademark of International Business Machines Corporation in the United States and other countries.) The FlashCopy® can be used with standard backup tools that are available in the environment to create backup copies on tape. A FlashCopy® function creates a copy of a source volume on a target volume. This copy, as mentioned above, is called a point-in-time copy. When a FlashCopy® operation is initiated, a relationship is created between a source volume and target volume. This relationship is a “mapping” of the source volume and the target volume. This mapping allows a point-in-time copy of that source volume to be copied to the associated target volume. The relationship exists between this volume pair from the time that the FlashCopy® operation is initiated until the storage unit copies all data from the source volume to the target volume, or the relationship is deleted.
When the data is physically copied, a background process copies tracks from the source volume to the target volume. The amount of time that it takes to complete the background copy depends on various criteria, such as the amount of data being copied, the number of background copy processes that are running and any other activities that are presently occurring. The FlashCopy® function works in that the data which is being copied does not actually need to be copied instantaneously, it only needs to be copied just prior to an update causing an overwrite of any old data on the source volume. So, as data changes on the source volume, the original data is copied to the target volume before being overwritten on the source volume.
Therefore, a FlashCopy® is a feature supported on various storage devices that allows a user or an automated process to make nearly instantaneous copies of entire logical volumes of data. A copy of a source disk is made on a target disk. The copies are immediately available for both read and write access. A common feature of FlashCopy® like implementations is the ability to reverse the copy. That is, to populate the source disk of a FlashCopy® map with the contents of the target disk. It is also possible to use FlashCopy® in cascaded implementations, in which a target disk later becomes the source disk for a further FlashCopy® or vice versa.
A cascaded configuration of storage volumes is described in detail in U.S. Pat. No. 7,386,695. It is also possible to create multiple cascades of storage volumes which are interlocking at a logical level. A first cascade may comprise storage volumes A, B, C and D which are arranged in a cascade as follows: ABCD, while at a later time a new backup of A may be started that ultimately leads to the creation of AEF. Many different combinations of FlashCopy® functions and reversed functions are possible, potentially creating complicated multiple cascading storage volumes.
In order to keep track of such cascaded storage volumes and FlashCopy® functions it is preferable to provide a data structure that defines primary and secondary “fdisks”. An fdisk is a logical component that includes an index defining the storage volume to which the fdisk relates and providing links to the relevant maps that define the up and down directions of the FlashCopy® functions in a cascade. When a FlashCopy® function is created between a source volume and a target volume, then primary fdisks are created for each storage volume, unless a primary fdisk already exists for the target disk, in which case that existing fdisk for the target volume is converted to a secondary fdisk and a new primary fdisk is created. The advantage of using a data structure as defined by the fdisks is that the fdisks can be used to keep track of the IO read and write accesses to different storage volumes within existing multiple cascades and direct data reads to the correct location within the cascade.
The use of the concept of fdisks allows a storage volume to appear in different FlashCopy® cascades concurrently. The more times that a disk appears in a cascade the more IO operations may be required at the FlashCopy® level (cleaning IOs) before a host originated IO can be completed back to the host. For this reason the number of fdisks for each disk is typically limited (for example to 2). This will, in turn, limit the number of active FlashCopy® backup or restore operations that can be started in a cascade, whilst any existing maps are still active. One way around this problem is to collapse cascades containing fdisks from the same disk back into a single cascade. There are however problems with reforming a single cascade which normally require unpleasant restrictions. Two examples are given below.
In a first example, suppose there are disks A, B, C, D, E and F. There are created FlashCopy® maps A→B, A→C, A→D, A→E and A→F. If the system started the maps A→D, A→C and A→B in order then there will be the cascade A→B→C→D. After A→D completes, there will result a cascade A→B→C. If it is now discovered that disk A is corrupt and the administrator wishes to restore from disk A from disk D, then there is created and started a map D→A, which results in cascades D→A and A→B→C. Before FlashCopy® D→A is completed, the administrator wishes to continue making backups of disk A. So there are started maps A→F and A→E, before D→A is completed. This ends up with cascades D→A→E→F and A→B→C.
In this scenario, the administrator is now stuck with two fdisks for A, until either A→B and A→C stop or complete, or D→A stops or D→A and A→E complete. If disk A was to again become corrupted, the administrator would be unable to restore disk A again until one of these were to happen. Now if there is a restriction that it is only possible to write to the original source disk A then when D→A completes it is possible to naturally return the cascade configuration to A→E→F→B→C, because the cleaning required for writes to A mean that B is independent of any grains changed since D→A was started. However, this read-only target restriction means that the user cannot create FlashCopy® maps for development or test purposes, which maps that require their target to be writable. Thus the scenario has a restriction that is not overcome by any prior art solutions.
In a second example, suppose there are disks A, B, C, D, E and F. There is created FlashCopy® maps A→B, B→C, B→D, B→E and B→F. Suppose further that A→B is incremental and disks C, D, E and F are Space Efficient vdisks. The user starts maps A→B and then B→C giving a cascade A→B→C. When A→B completes a split stop will leave cascade B→C. Disk C is independent of disk A, so if disk A fails, then disk C is still available to the user. Now if the user starts A→B again, which completes quickly because it is incremental, it is also possible to start B→D. This gives cascades A→B→D and B→C. When A→B completes the user again split stops it and (to minimize the number of fdisks and allow the user again to restart A→B) the user wants to end up with cascade B→D→C. This will work fine provided only disk A and/or disk B is written to by the host. As with the previous example, this means that the user cannot create FlashCopy® maps for development or test purposes, maps that require its target to be writable. Thus the scenario has a restriction that is not overcome by any prior art solutions.